🤖 Review Bot Summary

Risk Level: MEDIUM

Per-Repo Breakdown

🔗 Cross-Repo Findings

• 🔵 [code-kern-ai/refinery-ui, code-kern-ai/cognition-ui, code-kern-ai/submodule-javascript-functions] Both consuming repos only change the submodules/javascript-functions gitlink (same SHA 1439989af851), with no accompanying TS/React edits in those PRs. That satisfies submodule alignment for this group as far as the visible diffs show.
• 🔵 [code-kern-ai/refinery-ui, code-kern-ai/cognition-ui, code-kern-ai/submodule-javascript-functions] The supplied cloned-repository evidence contained no submodule pointers (.gitmodules, nested submodule revisions), git SHAs tying refinery-ui PR #101 or cognition-ui PR #220 to submodule-javascript-functions PR Hotfix for depricated kimi model #37, or documentation of the intended tip for 1439989. With no such material, whether 1439989 is the agreed merge/revision and whether both UIs pin the same submodule content cannot be confirmed or refuted from the evidence; manual check of those PRs and submodule commits in the real repos is still needed.
• 🔵 [code-kern-ai/submodule-javascript-functions, code-kern-ai/refinery-ui, code-kern-ai/cognition-ui] The evidence only covers this submodule map; it does not include refinery-ui, cognition-ui, persisted org/user data, URLs, flags, or telemetry. The map no longer defines kimi-k2.5, but residual reliance elsewhere in those apps cannot be verified from the provided files.
• 🔵 [code-kern-ai/submodule-javascript-functions, code-kern-ai/refinery-ui, code-kern-ai/cognition-ui] The supplied evidence is limited to constants.ts model display/ mapping keys; no API routes, OpenAPI, SQL, or HTTP clients appear. That supports the finding that end-to-end contract consistency with backends or other repos cannot be established from this material and any parallel catalogs or server-side validation would need separate verification or coordinated rollout.
• 🟡 [code-kern-ai/refinery-ui, code-kern-ai/cognition-ui, code-kern-ai/submodule-javascript-functions] After merging, smoke-test model selection/display paths in both UIs against the updated submodule build to catch runtime mapping failures that would not appear in these pointer-only PR diffs.

Inline comments with details are posted on each PR above.

The following queries against the PROD DB did not return any references to kimi, I guess nothing is using this model in PROD so no intervention required in that regard:

-- attribute calculation
select
	o.id,
	o.name,
	a.project_id,	
	p.name,
	a.id,
	a.name,
	additional_config
from public.attribute a
join public.project p on a.project_id = p.id
join public.organization o on p.organization_id=o.id
where lower(additional_config::varchar) like '%kimi%';

-- Cognition Strategy steps
select
	o.id,
	o.name,
	ss.project_id,	
	p.name,
	ss.id,
	ss.name,
	ss.config
from cognition.strategy_step ss 
join cognition.project p on ss.project_id=p.id 
join public.organization o on p.organization_id = o.id
where lower(config::varchar) like '%kimi%';

-- ETL configs
select * 
from cognition.etl_config_preset ecp 
where lower(ecp.etl_config::varchar) like '%kimi%' ;